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Abstract 

Architectural  views,  as  defined  by  the  Department  of  Defense’s  (DoD)  Command, 
Control,  Communications,  Computer,  Intelligence,  Surveillance  and  Reconnaissance 
(C4ISR)  framework,  are  used  as  a  prism  to  develop  a  management  structure  for 
implementing  programs  distributed  across  multiple  organizations.  This  structure  is  also 
useful  in  managing  smaller  efforts  within  an  evolutionary  acquisition  program.  The 
paper  recommends  a  matrix  that  defines  management  tasking  across  multiple 
management  layers,  and  in  terms  of  the  three  C4ISR  architectural  views.  The  matrix 
provides  a  template  for  assigning  technical  and  programmatic  responsibilities  across 
organization  levels  and  suggests  where  stakeholders  should  place  their  primary  focus. 
Individual  projects  also  are  shown  to  each  have  zones  of  optimal  technical  enhancement 
that  form  a  continuous  improvement  band  in  which  systems  may  evolve  and  technology 
may  be  inserted  to  enhance  system  wide  performance.  The  author  applies  this  template 
to  the  Joint  Tactical  Radio  System  (JTRS)  Joint  Program  Office  (JPO)  and  discusses 
appropriate  management  focus  within  the  context  of  the  JTRS  JPO’s  primary  role  as  an 
integrating  program  management  office  charged  with  directing  an  evolutionary 
acquisition  program. 

Introduction 

The  Joint  Tactical  Radio  System  (JTRS)  Program  is  a  major  DoD  effort  aimed  at 
replacing  virtually  every  radio  and  radio  system  within  the  Department.  The  program 
spans  over  two  decades,  and  across  all  four  Services.  JTRS  is  an  evolutionary  acquisition 
effort  and  system  capabilities  will  be  fielded  over  time  as  technology  enhancements 
become  available.  To  manage  this  program  of  programs,  the  Office  of  Secretary  of 
Defense  (OSD)  established  a  Joint  Program  Office  (JPO). 

The  JPO’s  role  is  to  manage  the  overall  program  across  Clusters  and  to  assure  that  the 
developed  systems  are  interoperable  and,  in  the  long-term,  integrated  into  a  single 
networked  communications  system.  The  JPO  is  also  responsible  for  developing 
waveform  applications  and  the  Software  Communications  Architecture  (SCA)  upon 
which  the  JTRS  programmable  radio  is  based.  The  Cluster  managers  are  tasked  to  build 
systems  for  their  assigned  domains  and  to  meet  the  requirements  set  forth  in  the 


Operational  Requirements  Document  (ORD)  that  pertain  to  their  acquisitions.  Program 
execution  responsibilities  are  thus  split  among  separate  Cluster  managers,  the  JPO,  and 
other  stakeholders. 

Establishing  the  proper  level  of  responsibilities  and  task  sharing  among  the  various 
organizations  responsible  for  producing  components  of  the  JTRS  is  key  to  properly 
managing  the  program.  JPO  leadership  must  determine  at  what  level  within  and  across 
multiple  organizations  various  responsibilities  should  be  placed,  as  well  as  the  specific 
levels  of  detail  that  should  be  addressed  by  different  individuals  within  these 
organizations.  Focus  must  be  maintained,  as  managers  and  engineers  work  at  different 
levels  and  with  varied  degrees  of  detail,  to  assure  that  each  Cluster  develops  its  part  of 
the  JTRS  system  within  the  overarching  JTRS  framework. 

This  paper  will  first  briefly  explain  the  evolutionary  acquisition  process  identified  by  the 
May  12th  2003  Department  of  Defense  Instruction  (DoDI)  5000.2  as  the  acquisition 
method  of  choice.  It  will  then  explain  the  C4ISR  Architecture,  and  illustrate  its  use 
within  the  DoD  Architecture  Framework  VI.  The  JTRS  program  is  then  outlined  and  the 
C4ISR  architecture  views  are  applied.  The  paper  also  draws  conclusions  regarding  the 
primary  role  of  the  JTRS  JPO  as  the  overall  integrating  program  management  office. 
Using  the  C4ISR  views  leads  to  developing  a  table  that  breaks  down  program 
responsibility  and  provides  focus  for  program  and  project  managers  within  the  JTRS 
effort. 

Evolutionary  Acquisition  and  DoD  Architectural  Updates 

On  May  12,  2003,  DoD  issued  new  acquisition  policy  guidance,  codifying  many 
innovations  and  streamlining  initiatives  instituted  within  the  Department  over  the  last 
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decade.  The  most  sweeping  change  is  a  movement  away  from  the  traditional  linear 
acquisition  process  that  guided  the  DoD’s  acquisition  policy  since  its  inception.  An 
evolutionary  acquisition  model  was  chosen  as  the  preferred  acquisition  method  for  all 
DoD  acquisitions.  The  model  is  pictured  in,  Figure  1,  above,  in  a  simplified  illustration 
taken  from  the  DoDI  5000.2.  Remnants  of  the  old  linear  system  can  be  seen  in  the 
milestone  (MS)  A,  B  and  C  decision  points.  Specific  elements  of  each  MS  review  have 
been  redefined  within  the  current  5000.2  document.  Within  this  new  approach,  programs 
are  split  into  increments  and  each  increment  must  pass  its  own  MS  B  and  C  decision 
points.  The  Joint  Requirements  Oversight  Council  (JROC)  and  the  Defense  Acquisition 
Board  (DAB)  now  review  requirements  iteratively  within  each  incremental  build  and 
feed  new  or  modified  requirements  and  acquisition  guidance  back  into  the  next 
incremental  build.  The  chief  evolutionary  mechanism  within  this  system  is  the  injection 
of  technology  through  demos,  leading  to  each  new  incremental  build.  Now  major 
programs  may  no  longer  have  a  constant  set  of  requirements  as  defined  within  an 
Operational  Requirements  Document  (ORD)  or  charter  approved  by  the  DAB.  The 
process  embraces  change  at  all  layers,  from  requirements  definition  to  nonmaterial 
development  (i.e.,  training,  procedures,  doctrine  and  tactics)  and  material  acquisition. 
This  process  is  monitored  by  Overarching  Integrated  Product  Teams  (OIPTs)  that  look  to 
the  integration  of  material  and  nonmaterial  solutions  with  regard  to  material  solutions, 
system  requirements  and  integration  issues  within  and  between  incremental  builds. 

This  change  in  the  DoD  acquisition  approach  has  fundamentally  transformed  the 
principal  role  of  major  program  offices.  The  traditional  program  management  functions 
(meeting  cost,  schedule  and  requirements  across  many  projects  within  a  particular 
program)  must  still  be  met  as  programs  are  implemented  along  each  incremental  build  of 
an  evolutionary  acquisition  effort.  However,  the  program  office  must  now  manage  a 


Figure  2 


portfolio  of  programs  across  increments. 


Figure  2  shows  a  well-known  graph  that  depicts  the  relationship  between  project  maturity 
and  cost  in  making  engineering  design  changes  over  time.  The  figure  is  based  on  a 
traditional  acquisition  process  and  its  primary  tenants  hold  true  for  all  programs.  As 
shown,  at  the  beginning  of  a  project  there  are  many  options  for  designers  and  conceptual 
breadth  is  great.  At  the  same  time,  program  details  such  as  design  parameters  and 
specific  system  interfaces  may  be  lacking.  Since  the  engineering  design  is  not  yet  well 
defined,  changes  can  be  accomplished  with  relatively  low  cost.  Correspondingly,  as  time 
goes  on,  the  design  becomes  better  defined  and  more  specific  details  are  known  with 
regard  to  system  operation,  interfaces  and  technical  design.  With  time,  the  conceptual 
breadth  or  design  options  are  reduced  and  any  changes  tend  to  cost  more  because 
redesigns  require  that  new  hardware  must  be  built.  From  a  single  project  or  program 
perspective,  there  is  a  period  that  is  optimal  for  design  changes,  given  the  available 
design  detail  and  cost  of  change  as  depicted  by  the  single  oval  in  Figure  2. 

As  shown  in  Figure  3,  each  Cluster  program  within  the  JTRS  acquisition  effort  matures  at 
a  different  rate  over  time.  This  results  in  displaced  and  possibly  overlapping  zones  of 
optimal  engineering  change  for  each  Cluster  program.  Within  the  JTRS’  evolutionary 
acquisition  process,  the  JPO’s  primary  challenge  is  to  manage  across  Clusters  and  over 
time  to  smoothly  enhance  system  capabilities  in  support  of  near-,  mid-  and  long-term 
program  objectives  and  requirements.  By  applying  well-defined  standards  and 
specifications,  the  JPO  must  shape  the  JTRS  program  evolution  within  an  overall 
architectural  framework  that  provides  for  future  enhanced  capability  and  meets  long-term 
Joint  Vision  (JV)  objectives.  The  primary  risks  to  evolutionary  change  are  the  likelihood 
that  a  Cluster  will  design  and  build  a  system  element  that  blocks  this  future  growth 


capability,  or  that  incremental  requirements  could  move  system  capabilities  away  from 
the  overarching  JV  objectives. 


The  preceding  discussion  has  focused  on  Clusters  because  of  the  unique  challenge  posed 
by  multiple  programs  within  the  JTRS  acquisition  program.  The  challenge  is  even  greater 
when  one  realizes  that  each  Cluster  may,  as  part  of  its  own  multi-service  acquisition 
program,  be  an  independent  evolutionary  acquisition  effort  with  its  own  incremental 
development  schedule.  The  high-level  management  goal  is  still  the  same:  managing 
change  to  foster  the  orderly  evolutionary  development  of  the  overall  system.  The  key  is 
to  properly  manage  the  continuous  zone  of  evolutionary  system  enhancement.  As  seen  in 
Figure  3,  this  zone  is  formed  by  the  overlapping  of  individual  project  zones  of  optimal 
change. 

At  a  portfolio  management  level,  the  principal  role  of  the  integrating  program  manager  is 
managing  this  change  and  assuring  that  decisions  made  within  each  increment  allow  for 
continued  product  improvements  within  the  evolutionary  acquisition  process.  Project  and 
program  managers  must  now  be  attuned  to  strategic  issues  and  long-term  considerations 
as  they  manage  across  shorter-term  incremental  builds. 

The  C4ISR  architectural  framework  (now  integrated  within  the  draft  OSD  Architecture 
Framework  VI)  provides  an  excellent  tool  for  viewing  various  parts  of  a  program.  As 
will  be  shown  below,  the  C4ISR  views  provide  a  structure  by  which  technical  and 
program  managers  may  analyze  a  system.  Each  C4ISR  view  allows  managers  to 
decompose  elements  of  the  program  into  logical  blocks,  based  on  what  portion  of  the 
program  is  being  worked.  The  remainder  of  this  paper  will  look  at  the  C4ISR  views  and 
how  they  may  be  applied  to  manage  a  large  evolutionary  acquisition  program  across 
multiple  incremental  builds— and  in  the  case  of  the  JTRS  program,  multiple  Cluster 
acquisition  efforts. 

Defining  the  C4ISR  Views 

In  December  1997  the  DoD  C4ISR  Architecture  Working  Group,  under  the  auspices  of 
the  Directorate  for  C4I  Integration  (now  call  Network  and  Information  Integration  Office 
/  Nil),  published  a  final  report  defining  a  framework  for  C4ISR  systems.  This  report  is 
the  second  iteration  of  the  DoD  sponsored  framework  and  is  widely  accepted  throughout 
DoD.  The  framework  provides  the  strategic  definition  and  underlying  means  to  view  all 
C4ISR  architectures  within  the  DoD.  Its  major  elements  are  depicted  in  Figure  4  below. 
The  Institute  for  Electrical  and  Electronic  Engineers  (IEEE)  defines  architecture,  in  IEEE 
610.12,  as  the  organizational  structure  of  a  system  or  component,  system  or  component 
relationships,  and  the  principles  and  guidelines  governing  design  and  evolution  over  time. 
The  DoD  has  implemented  this  definition  by  specifying  the  interrelated  set  of 
architectures  depicted  in  Figure  4  above.  These  architectures  are  defined  in  version  two 
of  the  DoD  framework  as  “Operational,”  “Systems,”  and  “Technical”.  Figure  4  also 
shows  the  relationship  among  these  architectural  views.  The  definitions  from  the  C4ISR 
Architecture  Framework  V2.0  are  provided  below  to  ensure  a  common  understanding  of 
each  view. 
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•  Operational  View  (OV):  A  description  (often  graphical)  of  the  operational 
elements,  assigned  tasks,  and  information  flows  required  to  accomplish  or 
support  the  warfighting  function.  It  defines  the  type  of  information,  the 
frequency  of  exchange,  and  the  tasks  supported  by  these  information 
exchanges.  [1] 

•  Technical  View  (TV):  A  minimal  set  of  rules  governing  the  arrangement, 
interaction,  and  interdependence  of  the  parts  or  elements  to  ensure  that  a 
conformant  system  satisfies  a  specified  set  of  requirements.  The  technical 
architecture  (view)  identifies  the  services,  interfaces,  and  standards,  and  their 
relationships.  It  provides  the  technical  guidelines  for  implementing  systems 
upon  which  engineering  specifications  are  based,  common  building  blocks  are 
built,  and  product  lines  are  developed.  [1] 

•  Systems  View  (SV):  A  description,  including  graphics,  of  systems  [2]  and 
interconnections  [3]  providing  for  or  supporting  warfighting  functions  (C4ISR 
ITF  Integrated  Architecture  Panel,  18  December  1995).  The  SV  defines  the 
physical  connection  and  location;  identifies  the  key  nodes,  circuits,  networks, 
war  fighting  platforms,  etc.;  and  specifies  system  and  component  performance 
parameters.  It  is  constructed  to  satisfy  Operational  Architecture  (view) 
requirements  per  standards  defined  in  the  Technical  Architecture  (view).  The 
SV  shows  how  multiple  systems  within  a  subject  area  link  and  interoperate, 
and  may  describe  the  internal  construction  or  operations  of  particular  systems 
within  the  architecture.  (C4  Chiefs  Consensus  SA  Definition,  12  January 
1996,  as  modified  at  the  suggestion  of  the  USD  (A&T)  community).  [1] 


The  C4ISR  architecture  also  forms  the  basis  for  the  DoD  Architecture  Framework 
Version  1,  published  in  draft  form  on  15  January  2003  and  recently  approved  for  use  via 
OSD  Memorandum,  February  9,  2004,  Subject:  The  Department  of  Defense  Architecture 
Framework  (DoDAF).  Figure  5,  below  when  compared  with  Figure  4,  above,  shows  that 


o*  JZ* 


r'S 

W4 


Operational 

View 


Identifies  Participant  Relationships 
and  Information  Needs 


h 


\% 


% 


Systems 

View 


Relates  Capabilities  and  Characteristics 
to  Operational  Requirements 


Ir 

◄ 


Specific  Capabilities 
Required  to  Satisfy 
Information  Exchanges 


Technical  Criteria  Governing 
Interoperable  Implementation/ 
Procurement  of  the  Selected 
System  Capabilities 


Figure  5 


Technical  Standards 
View 


Prescribes  Standards  and 
Conventions 


the  draft  DoD  Architecture  VI  closely  parallels  the  older  C4ISR  architecture  V2.  The 
application  of  the  C4ISR  framework  to  the  more  general  DoD  framework  illustrates  the 
broad  applicability  of  the  C4ISR  architecture.  The  DoD  VI  architecture  is  anticipated  to 
eventually  eclipse  the  original  C4ISR  framework.  However,  the  C4ISR  framework 
remains  more  widely  known,  and  the  relevant  portions  of  the  two  frameworks  are 
essentially  the  same.  Therefore  the  remainder  of  this  paper  will  use  the  C4ISR 
architecture  as  the  framework  to  organize  a  large  distributed  program  management  office 
structure. 


System  Definition 

The  C4ISR  architecture’s  ability  to  act  as  a  decomposing  prism  for  complex 
communications  systems  is  extremely  useful  in  developing  and  managing  those  systems. 
Figure  6  depicts  the  components  that  describe  a  complex  system  such  as  the  JTRS.  It  is 
based  on  DoD  guidance  as  explained  in  the  C4ISR  Architecture  and  tailored  for  the  JTRS 
program.  As  with  any  complex  system,  the  JTRS  is  composed  of  Hardware,  Software 
and  supporting  Architectures.  Specifications  tend  to  drive  the  engineering  design, 
whereas  standards  tend  to  drive  the  engineering  approach.  Architectures  tie  together 
hardware  and  software;  hence,  both  standards  and  specifications  tend  to  drive  architecture 
definitions.  Together,  software,  hardware  and  supporting  architectures  completely  define 
the  JTRS. 


The  JTRS  may  be  decomposed  into  its  component  hardware,  software  and  architecture 
elements  as  depicted  by  the  top  set  of  circles  in  Figure  6.  A  single  JTRS  component  is 


depicted  within  the  overlapping  circles  and  is  defined  by  its  hardware  design,  loaded  or 
imbedded  software,  and  internal  architecture  design.  The  JTRS  is  made  up  of  multiple 
components  networked  together  within  a  unifying  architecture.  The  JTRS  can  be  viewed 
at  varying  levels  of  complexity  and  detail,  based  on  the  C4ISR  view  used.  These  views 
are  interrelated,  and  together  they  form  a  complete  picture  of  a  system  or  end  item.  Each 
view  can  be  thought  of  as  a  separate  color  screen  used  to  form  a  full-color  picture.  When 
each  screen  is  separated  (i.e.,  into  red,  green  and  blue)  the  picture  becomes  decomposed 
and  information  concerning  each  color  component  is  discemable.  However,  when 
overlaid,  a  full  color  picture  can  be  seen.  Each  color  separation  may  be  adjusted 
independently  of  the  others;  however,  the  final  color  balance  of  the  picture  is  related  to 
the  interaction  of  each  color  separation.  We  will  next  address  the  use  of  these  views  to 
guide  management  emphasis  within  a  program. 

Levels  of  Management 

Each  view  of  the  C4ISR  Architecture  (operational,  system  &  technical)  attempts  to 
explain  interrelationships  from  a  slightly  different  focus  and  level  of  detail.  When 
moving  from  the  operational  view  towards  the  technical  view,  the  focus  tends  to  narrow, 
as  technical  detail  tends  to  increase.  However,  within  each  view  the  perspective  remains 
constant.  Within  the  operational  view,  requirements,  mission  and  system  interfaces  tend 
to  be  the  items  of  interest.  The  system  view  usually  examines  “box”  or  component 
interrelationships,  including  component  interfaces,  while  the  technical  view  is  concerned 
with  the  proper  implementation  of  standards  and  specifications  to  meet  technical 
interoperability  and  component  design.  These  views  thus  define  areas  of  interest  and 


serve  to  focus  managers’  and  engineers’  efforts,  depending  on  what  view  is  under 
consideration. 

As  an  example,  when  dealing  with  a  component  at  the  level  of  contract  management, 
design  engineers  are  primarily  concerned  with  standards  and  specifications  that  tell  how 
the  component  is  built.  At  the  system  level,  the  technical  focus  is  at  interfaces  between 
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components  and  the  network.  In  the  JTRS,  component  sets  are  tied  together  into  a 
complete  system  at  the  systems  level.  System  level  concerns  deal  with  traditional 
systems  engineering  functions,  and  products  at  this  level  tie  detailed  engineering  efforts 
at  the  technical  level  to  overarching  and  general  descriptions  at  the  operational  level.  The 
system  level  architecture  allows  components  described  in  the  operational  view  to  be 
appropriately  integrated  into  a  complete  system. 

Understanding  how  much  detail  to  apply  to  standards  and  specifications  at  each  level  of 
management  is  critical.  Figure  7  shows  the  level  of  detail  (solid  line)  and  the 
applicability  (dashed  line)  of  standards  at  three  generalized  management  levels.  From  a 
JPO  perspective,  standards  describing  the  JTRS  will  be  less  detailed  and  broadly 
applicable  across  the  Joint  arena.  However,  at  the  contract  level,  standards  or 
specifications  may  be  very  specific  and  more  numerous,  but  not  applicable  across  the 
entire  system. 


Lack  of  common  terms  across  the  engineering  and  acquisition  communities  may  create 
confusion.  For  example,  a  programmable  radio  set  may  contain  sub-components  that  are 
tied  together  within  a  component  box.  Each  sub-system  may  have  its  own  system  and 
technical  level  descriptions,  and  the  interconnection  of  these  sub-systems  would  be 
designed  according  to  some  interface  architecture.  A  program  manager  focused  solely  on 
this  single  box  may  have  projects  for  each  of  the  sub-systems  and  may  manage  interface 
requirements  between  sub-systems  through  system  and  technical  level  views  of  the  entire 
radio  set.  At  a  higher  level  of  management,  multiple  sets  may  be  part  of  a  larger  JTRS 
networked  system.  Technical  standards  for  each  set  may  form  the  basis  for  interface 
requirements  between  major  components  within  the  JTRS  system.  It  is  at  this  higher 
level  of  systems  management  that  the  C4ISR  framework  is  most  useful.  Looking  back  to 
Figure  6,  we  can  imagine  multiple  illustrations  depicting  any  level  within  the  entire  JTRS 
system.  At  the  enterprise  level,  a  network  of  multiple  radio  systems  may  be  pictured  in 
place  of  the  single  radio  set  illustrated.  Figure  8  illustrates  the  above  discussion. 


System  of  Systems 


Figure  8 


The  JPO’s  or  integrating  program  management  office’s  role  is  most  critical  at  the 
enterprise  level.  It  is  only  at  the  enterprise  level  as  depicted  in  Figure  8  as  a,  “systems  of 
systems,”  that  the  evolutionary  build  between  major  clusters  can  be  managed.  At  this 
level,  system  definition  and  functionality  are  managed  over  time  through  the  proper  use 
of  standards  and  specifications  at  each  level  (JPO,  Cluster  (multi-service)  and  individual 
contract),  and  through  configuration  management  between  levels.  The  role  of  the 
integrating  program  office  (in  this  case  the  JTRS  JPO)  becomes  the  management  of  a 
portfolio  of  programs  whose  collective  purpose  is  to  provide  an  integrated  system. 
Subsequent  discussions  within  this  paper  focus  on  the  enterprise  system  level 
management  of  complex  programs. 


The  technical,  system  and  operational  views  of  the  C4ISR  framework  parallel  the  above 
management  levels  shown  in  Figure  7  and  thus  provide  a  means  to  guide  the  level  of 
detail  associated  with  each  decomposed  C4ISR  layer.  For  example,  from  a  technical 
view,  both  hardware  and  software  specifications  and  standards  will  be  very  detailed. 
Architectural  elements  will  also  be  correspondingly  detailed.  As  one  moves  from  the 
technical  view  to  the  systems  and,  finally,  the  operational  view,  the  level  of  detail 
decreases.  Typically,  operational  level  views  are  cartoon-like,  whereas  technical  views 
tend  to  be  detailed  listings  of  specifications  and  standards  that  define  components  of  the 
system,  but  do  not  provide  a  “picture”  of  what  the  system  looks  like. 


The  Management  Matrix 

Table  1  highlights  specific  focus  areas  for  contract,  Cluster  and  joint  managers  and  shows 
where  they  should  focus  their  attention  based  on  the  C4ISR  views  and  their  respective 
management  levels  in  the  organization.  Some  focus  areas  repeat  between  organizational 
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Table  1 


levels  as  a  result  of  overlapping  structures  in  the  C4ISR  framework  and  its  widening 
areas  of  interest  as  one  moves  from  detailed  contract  management  to  the  Joint  level  of 
management. 

The  C4ISR  views  provide  program  management  a  context  from  which  to  develop  plans 
for  program  execution.  At  each  management  level,  staff  should  focus  on  items  primarily 
associated  within  the  corresponding  “Xed”  C4ISR  views.  The  “+”  marks  indicate  the 
need  for  all  levels  of  management  to  know  and  understand  operational  requirements  (but 
the  item  is  not  the  primary  consideration  at  that  particular  level  of  management).  The 
level  of  technical  detail  increases  as  one  moves  from  Joint  through  Cluster  to  Contract 
levels,  while  the  details  of  military  operations  lessen.  Conversely,  as  one  moves  from 


detailed  technical  views  to  more  general  operational  views,  the  details  concerning 
operational  considerations  increase. 

Looking  at  an  area  of  overlap,  Cluster  managers  share  their  focus  on  the  systems  view 
with  both  JPO  and  OSD  organizations.  This  overlap  provides  a  linkage  between  detailed 
specifications  and  standards  at  the  contract  level  and  system-wide  operational 
requirements  at  the  Joint  level  as  described  in  the  OV.  Looking  now  at  the  top  Joint  & 
Cluster  level,  OSD  provides  general  acquisition  oversight  through  assigned  Service 
Acquisition  Executives  (SAEs).  This  means  that  at  the  OSD  level  managers  or  engineers 
should  be  primarily  concerned  with  operational  and  system  level  views  of  the  overall 
broad  product  and  its  connecting  architecture. 

The  JPO’s  dual  roles  as  both  an  oversight  and  a  program  execution  agent  require  it  to 
work  within  all  the  C4ISR  views  and  to  focus  at  specific  levels  within  the  matrix  based 
on  the  management  role  being  preformed.  Waveform  application  development  and  SC  A 
management  are  natural  outgrowths  of  the  JPO’s  responsibility  for  overall  joint  program 
oversight.  However,  the  execution  of  the  waveform  program  requires  detailed  contract 
level  management  of  projects  that  lead  to  product  delivery  of  software  end  items.  The 
JPO  is  uniquely  positioned  to  also  provide  program-wide  configuration  management 
across  clusters  and  individual  contract  efforts.  For  example,  standards  and  specifications 
are  used  to  completely  define  systems,  especially  at  the  technical  level.  Contract 
managers  also  develop  system  specifications  and  standards  through  their  contract  efforts. 
Performance  specifications  are  developed  at  the  joint  and  Cluster  level.  The 
responsibility  for  overall  system  integration  resides  with  the  integrating  program  office 
(in  this  case,  the  JPO).  Therefore,  the  overall  configuration  management  (CM)  for  all 
levels  of  specifications  and  standards  must  reside  with  the  JPO. 

Importance  of  the  Approach 

The  layered  approach  to  technical  management  described  is  critical  when  managing  a 
portfolio  of  programs  at  the  integrating  Program  Management  Office  level.  One  of  the 
chief  challenges  in  maintaining  the  proper  focus  at  the  highest  levels  of  management  is 
the  ability  to  work  detailed  technical  issues,  without  getting  mired  in  the  low  level 
execution  of  individual  programs  and  projects.  At  the  same  time,  managers  and 
engineers  also  need  to  know  when  not  to  step  down  into  individual  programs  and  project 
execution  because  of  the  risk  of  losing  the  strategic  perspective  required  for  the 
management  of  a  portfolio  of  programs.  The  use  of  Table  1  to  set  management  and 
technical  focus  is  helpful  in  assessing  the  proper  focus  of  management  or  technical  effort 
given  one’s  place  within  an  organization.  Table  1  may  also  be  used  in  managing  multiple 
programs  that  are  at  different  phases  within  their  program  cycles. 

The  C4ISR  framework  and  Table  1  also  plays  an  important  role  in  defining  the 
organizational  focus  for  programs  managed  at  the  integrating  program  office  level. 
Figure  2  shows  that  over  time  the  technical  definition  of  the  program  increases  as 
program  flexibility  decreases.  Thus  as  programs  within  a  managed  portfolio  mature, 
different  aspects  of  the  architectural  views  will  be  more  important  than  others.  Control  of 
the  continuous  zone  of  evolutionary  system  enhancement  depends  upon  coordinated 


control  of  operational,  system  and  technical  level  views  over  time.  Using  the 
management  matrix  in  Table  1,  program  personnel  can  properly  adjust  their  technical 
focus  based  on  where  they  sit  in  an  organization  and  the  maturity  of  a  particular  program. 

Conclusions 

This  paper  demonstrates  that  the  architectural  views  defined  by  the  DoD’s  Command, 
Control,  Communications,  Computer,  Intelligence,  Surveillance  and  Reconnaissance 
(C4ISR)  framework  work  well  in  developing  a  structure  to  manage  multiple  programs 
and  projects  distributed  across  diverse  organizations  and  agencies.  The  C4ISR 
framework  is  used  to  provide  guidance  for  the  approriate  level  of  effort  and  focus  for 
program  and  project  managers  at  various  levels  within  a  multi-organizational  program. 
This  supports  development  of  a  management  matrix  that  defines  a  suggested  level  of 
effort  in  terms  of  the  three  C4ISR  architectural  views  across  management  layers.  This 
matrix  provides  a  template  for  assigning  technical  and  programmatic  responsibilities 
across  multiple  organization  levels,  and  suggests  the  primary  areas  of  focus  for  each 
stakeholder  and  project  manager,  given  their  places  within  the  organizational  structure 
and  the  current  phase  of  a  particular  project.  Overall  focus  is  determined  with  the 
understanding  that  an  evolutionary  system-wide  development  effort  is  accomplished 
through  managing  overlapping  individual  project  zones  of  optimal  engineering 
enhancement.  At  the  JPO  (or  integrating  program  management  office)  level,  the  focus 
for  an  evolutionary  acquisition  program  is  on  managing  this  continuous  zone  of 
enhancement  to  allow  an  ordered  growth  in  capabilities  over  time. 

End  Notes 

[1]  These  definitions  are  extracted  from  the  C4ISR  Architecture  Framework.  The 
definitions  and  the  products  required  by  the  framework  focus  on  information  technology. 
However,  the  concepts  described  can  be  applied  to  a  wide  range  of  technologies.  The 
most  recent  update  to  the  C4ISR  adopted  the  idea  of  “Views”  as  opposed  to  three  sub¬ 
architectures. 

[2]  Systems:  People,  machines,  and  facilities  organized  to  accomplish  a  set  of  specific 
functions  (FIPS  PUB  3),  which  cannot  be  further  subdivided  while  still  performing 
required  functions.  Includes  the  radios,  terminals,  command,  control,  and  support 
facilities,  sensors  and  sensor  platforms,  automated  information  systems,  etc.,  necessary 
for  effective  operations. 

[3]  Interconnections:  The  manual,  electrical,  or  electronic  communications  paths/linkages 
between  the  systems.  Includes  the  circuits,  networks,  relay  platforms,  switches,  etc., 
necessary  for  effective  communications. 
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